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Requirements for IETF Technical Publication Service 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 

Abstract 
The work of the IETF is to discuss, develop, and disseminate 
technical specifications to support the Internet’s operation. 
Technical publication is the process by which that output is 


disseminated to the community at large. As such, it is important to 
understand the requirements on the publication process. 
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1. Introduction 


The work of the IETF is to discuss, develop, and disseminate 
technical specifications to support the Internet’s operation. 
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Therefore, an important output of the IETF is published technical 
specifications. The IETF technical publisher is responsible for the 
final steps in the production of the published technical 
specifications. This document sets forth requirements on the duties 
of the IETF technical publisher and how it interacts with the IETF in 
the production of those publications. 
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The term "technical specification" is used here purposefully to refer 
to the technical output of the IETF. This document does not engage 
in the debate about whether it is expressed as RFCs or otherwise, 
what "is" an RFC, how to classify them, etc. These issues are 
considered out of scope. 


The intention of this document is to clarify the IETF’s consensus on 
its requirements for its technical publication service. It is 
expected to be used in the preparation of future contracts. This 
document is not a discussion of how well the current technical 
publisher (the RFC Editor) fulfills those requirements. 


2. Scope 


The scope of this document is the requirements for the technical 
publication process for the IETF. Requirements on a technical 
publisher can be expressed in terms of both what tasks the IETF 
technical publisher is responsible for and performance targets the 
IETF technical publisher should meet. The functions provided by the 
technical publisher are sometimes referred to as editorial management 
[RFC2850]. 


This document specifically addresses those documents published by the 
IETF technical standards process. In all cases, the requirements 
have been written in generic terms, so that they may be used to 
express the requirements of other publication streams, elsewhere. 


The list of potential technical publication tasks was derived by 
considering the tasks currently performed by the RFC Editor as well 
as the responsibilities of the technical publishers in other 
standards organizations including 3GPP, ATIS, ETSI, IEEE, and ITU. 


This requirements document focuses on process issues in how the IETF 
technical publisher serves the IETF. There are related issues 
regarding non-technical aspects of document content that are not 
addressed in this requirements document. Issues not addressed in 
this document are: 


o Policies governing the acceptable input and output document 
formats (including figures, etc.) 


o Policies governing the acceptable character sets 
(internationalization) 


o Policies governing the layout and style of published documents 


o Policies governing the contents of non-technical sections 
(acknowledgement sections, reference classifications, etc.) 
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It is realized that the above policies are also important aspects in 
determining that the final published document is a product of the 
IETF. These policies are likely to evolve as part of the ongoing 
IETF dialog. The IETF technical publisher should be part of the 
discussions of these policies and be prepared to implement and 
facilitate policy changes as they are determined by IETF consensus. 
This requirement is captured under the discussion of process and 
document evolution. 


2.1. Stages in the Technical Specification Publication Lifetime 


Figure 1 below provides a useful summary of where technical 
publication falls in the current lifetime of a document in the IETF 
standards process. This figure shows a Working Group (WG) document 
and the reviews including Working Group Last Call (WGLC), Area 
Director (AD) review, IETF Last Call (IETF LC), IANA review, and IESG 
review. The document shepherd (shown in the diagram as "Shepherd") 
is an individual designated by the IESG to shepherd a document 
through the reviews and the publication process and is often not an 
AD. The lifetime is very similar for AD-sponsored IETF documents, 
such as documents that update IETF protocols for which there is no 
longer a working group, or documents on interdisciplinary topics. 


Actors Formal Actors Actors 
Reviews 

| Author, | WGLC | IESG, | | TIANA, 

Editor, AD Shepherd, A Tech 

IETF Sec- IETF LC Editor, P Publisher, 
| retariat | IANA | WG, | P | input from 
| | IESG | AD | R | authors, et al. 
| | | |o] 

Actions | Creation, | | Resolution | v | Non-author 
Editing, of all A editing, 
Draft Pub, reviews L other 

| Tracking | | | | publication 
|--------------- | |--------------------- | |---------------- 
In WG Out of WG Post-—approval 


Figure 1: Stages of a Working Group Document 


Note that in some cases a single submission may actually consist of 
multiple source documents (supporting files, code, etc.). 


Under the IETF standards process stream, the post-approval processing 
is initiated by the IESG after technical approval. 
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3. Technical Publication Tasks and Requirements 


Standards development organizations all have technical publication as 
part of their process. However, the boundaries between what is done 
by the technical committees and the technical publisher vary. 


The following are potential tasks of a technical publisher. The 
following list was derived after analyzing the technical publication 
policies of the IETF and other standards development organizations. 


1. Pre-approval review or editing 
2. Preliminary specification availability 
3. Post-approval editorial cleanup (non-author editing) 


4. Validation of references 

5. Validation of formal languages 

6. Insertion of parameter values 

7. Post-approval, pre-publication technical corrections 
8. Allocation of permanent stable identifiers 
9. Document format conversions 

10. Language translation 

11. Publication status tracking 

12. Expedited handling 

13. Exception handling 

14. Notification of publication 

15. Post-publication corrections (errata) 

16. Indexing: maintenance of the catalog 

17. Access to published documents 

18. Maintenance of a vocabulary document 


19. Providing publication statistics and status reports 
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20. Process and document evolution 
21. Tutorial and help services 
22. Liaison and communication support 


For each of these tasks, we discuss its relevance to the IETF and how 
it is realized within the IETF processes. Based upon this 
information, we derive requirements on the IETF technical publisher. 


3.1. Pre-approval Review or Editing 


Task Description: This provides a review or editing service to 
improve document quality prior to the approval of a document. This 
review process would normally address issues such as grammar, 
spelling, formatting, adherence to pre-approval boilerplate, document 
structure, etc. 


Discussion: Pre-approval review is not part of the current IETF 
standards process, but this concept has been explored in the early 


copyediting experiment. Early feedback from the experiment has been 
promising; however, the effectiveness of early editing is still being 
evaluated. 


Derived Requirements: 


Req-PREEDIT-1: The IETF technical publisher should be capable of 
performing an editorial review of documents early enough to allow 
changes to be reviewed within the technical review process, should 
the IETF choose to implement pre-approval editing. For the IETF 
standards process stream, this review should be performed before WG 
Last Call and provide feedback to the authors to improve the quality 
of the documents. For the IETF standards process stream, the 
publisher should not perform a technical review of the document. 


3.2. Preliminary Specification Availability 


Task Description: Some standards organizations require their 
publisher to make available a preliminary version of a document (with 
appropriate caveats) to make the information available to the 
industry as early as possible. This document is provided "as is" 
after the approval. This document is withdrawn once the final 
document is published. 
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Discussion: This is not required. A final approved version is 


available as an internet draft. If publication can take more than 6 
months, it may be necessary to request that the draft version remains 
available. 


Derived Requirements: none 
3.3. Post-approval Editorial Cleanup (Non-author Editing) 


Task Description: Most technical publishers do an editorial review to 
ensure the quality of published documents. Typically, this may 
address issues such as grammar, spelling, readability, formatting, 
adherence to boilerplate, document structure, etc. Since any 
proposed changes occur after approval, a review and signoff mechanism 
should usually be established to ensure that the required changes are 
truly editorial. Since such changes occur outside of the normal 
approval process, it is desirable that such changes are minimized. 
Most standards organizations target "light" editing due to the 
dangers of changing agreed-on text. 


Discussion: Within the IETF, the RFC Editor does post-approval 
cleanup review and editing. The ambition level for cleanup can vary 
from: 


o corrections to errors only, 
o light rewriting, 


o significant editing of documents with less skillful WG editors, 
and minimal editing when the WG editors were skilled, to 


o rewriting of all documents to the dictates of a style manual. 


At times in the past year, stylistic editing has resulted ina 
substantial number of changes in many documents. These changes must 
then be vetted by all the authors followed by subsequent rounds of 
author acceptance and re-vetting. This can add up to a substantial 
delay in the publication process, which must be weighed against the 
incremental gain in communication improvement accomplished by the 
cleanup. 


Changes to improve readability (or possibly even grammar) can end up 
inadvertently affecting consensus wording or technical meaning. Note 


that pre-approval editing to some extent avoids this problem. 


In specific instances, it may be necessary to require that text be 
published "verbatim" even if doing so introduces what is perceived as 
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poor readability or stylistic inconsistency. Examples of this 
include: 


"Boilerplate" agreed on in an IETF working group to apply to all 
instances of derivative works (e.g., IANA registration documents 
and Management Information Bases (MIBs)). 


Text referring to other organizations’ work that has been 
carefully phrased and arranged with representatives of that other 
organization to deal with some politically sensitive issue. 


If pre-approval editing or review is done, it may be possible to 
reduce or even eliminate entirely the post-approval editing task in 
some cases. Pre-approval editing may be more efficient since a 
separate change control process is not required. 


Derived Requirements: 


(0) 


Req-POSTEDIT-1 - The IETF technical publisher should review the 
document for grammar, spelling, formatting, alignment with 
boilerplate, document structure, etc. The review should strive to 
maintain consistency in appearance with previously published 
documents. In the IETF standards process stream, the publisher 
should not perform a technical review of the document. 


Req-POSTEDIT-2 - All changes made to post-approval documents 
should be tracked and the changes must be signed off on by the 
appropriate technical representatives. For the IETF standards 
process stream, this includes the authors, the document shepherd 
(if there is one), and the Area Director. The Area Director is 
the authority for approval of all changes. 


Req-POSTEDIT-3 - The IETF technical publisher should exercise 
restraint in making stylistic changes that introduce a substantial 
review load but only provide an incremental increase in the 
clarity of the specification. Specific guidelines on the types of 
changes allowed may be further specified, but ultimately restraint 
in editing must be imposed by the IETF technical publisher. 
Changes for stylistic consistency should be done only when there 
are major problems with the quality of the document. 


Req-POSTEDIT-4 - The IETF technical publisher should exercise 
restraint in making changes to improve readability that may change 
technical and consensus wording. Specific guidelines on the types 
of changes allowed may be further specified, but ultimately 
restraint in editing must be imposed by the IETF technical 
publisher. 
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o Req-POSTEDIT-5 - In specific instances, where some or all of 
document text is the result of a careful negotiation of 
contributions (within or between working groups, reviewers, etc.), 
the technical publisher may be required to publish that text 
verbatim. In the IETF standards process, verbatim publication may 
be requested by the IESG. It is the expectation of the IETF 
community that this will not be done often. 


3.4. Validation of References 


Task Description: Most standards organizations require that normative 
references be publicly available. Some technical publishers verify 
the validity and availability of references (including referenced 
clauses and figures). Although some editorial cleanup of references 
may be obvious, the issue becomes more severe when reference links 
are broken, are not publicly available, or refer to obsoleted 
documents. Such faults may be viewed as a post-approval fault found 
in the document. Most publishers have the ability to put a document 
on hold awaiting the publication of a reference expected to be 
available soon. 


Discussion: The RFC Editor may put a document on hold while waiting 
for the availability of other IETF documents. Incorrect references 
are handled like any other fault detected in the editorial review. 


Derived Requirements: 


o Req-REFVAL-1 - The IETF technical publisher should ensure that all 
references within specifications are currently available and are 
expected to remain available. 


o Req-REFVAL-2 - The IETF technical publisher should delay 
publication until all required (normative) references are ready 
for publication. 


3.5. Validation of Formal Languages 


Task Description: If the specification contains a formal language 
section (such as a MIB), the technical publisher may be required to 
validate this using a tool. 


Discussion: The RFC Editor syntactically validates sections of a 
document containing MIBs, Augmented Backus Naur Form (ABNF), 
eXtensible Markup Language (XML), Abstract Syntax Notation One 
(ASN.1), and possibly other formal languages. 
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Derived Requirements: 


o Req-FORMALVAL-1 - The IETF technical publisher should validate the 
syntax of sections of documents containing formal languages. In 
particular, ASN.1, ABNF, and XML should be verified using 
appropriate tools. 


3.6. Insertion of Parameter Values 


Task Description: The technical publisher is expected to work with 
IANA (or possibly other organizations maintaining registries) to 
populate assigned protocol parameter values when required, prior to 
publication. The population of these parameters values should not 
require technical expertise by the technical publisher. 


Discussion: Within the IETF, IANA normally does its allocations as an 
early step in the technical publication process. 


Derived Requirements: 


o Req-PARAMEDIT-1 - The IETF technical publisher should work with 
IANA in the population of required parameter values into 
documents. 


3.7. Post-approval, Pre-publication Technical Corrections 


Task Description: Regardless of efforts to minimize their occurrence, 
it is always possible that technical flaws will be discovered in the 
window between document approval and publication. The technical 
publisher may be requested to incorporate technical changes into the 
document prior to publication. Such changes necessitate a review and 
sign-off procedure. Another option is to disallow such corrections 
and treat them as post-publication errata would be treated. Note 
that this task is distinct from post-approval changes that might 
originate due to editorial review because they originate from outside 
the technical publisher. For severe flaws, it should always be 
possible to withdraw the document from the publication queue (see 
Section 3.13). 


Discussion: The IETF allows minor technical corrections during the 
publication process. This should ideally be a rare occurrence. 
Since any changes introduced during the post-approval phase can lead 
to publication delays, it is important that only changes with 
technical merit be permitted. In particular, stylistic changes 
should be discouraged. IETF processes must be in place to vet 
changes proposed by the author, but this is not specifically a 
requirement on the technical publisher. 
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The interaction between the authors and the technical publisher must 
be sufficiently well policed that untracked and unapproved changes 
cannot be introduced by the author or other parties. 


Derived Requirements: 


o Req-POSTCORR-1 - The IETF technical publisher should permit the 
incorporation of technical changes detected after approval but 
pre-publication. 


o Req-POSTCORR-2 - The IETF technical publisher should only allow 
post-approval technical changes that have been approved by the 
appropriate party. In the IETF standards process stream, this 
includes the authors and the Area Director. The document shepherd 
(if there is one) should be kept informed of these changes. 


o Req-POSTCORR-3 - The IETF technical publisher should alert the 
appropriate authority when it feels that a requested change is 
suspect (e€.g., an unapproved technical alteration) or unreasonable 
(e.g., massive editorial changes). Further processing of the 
draft should be suspended pending a response by that authority. 
For the IETF standards process stream, that authority is the Area 


Director. If there is a document shepherd working with the Area 
Director, the shepherd should be notified and kept informed as 
well. 


o Req-POSTCORR-4 - The IETF technical publisher should ensure that 
any source documents associated with a publication are updated in 
conjunction with their associated specifications. 


3.8. Allocation of Permanent Stable Identifiers 


Task Description: For a document to be referenced, it must have a 
unique permanent identifier. In some standards organizations, it is 
the technical publisher that generates this identifier. In other 
cases, the identifier may be allocated earlier in the process. 


Discussion: Currently, the RFC Editor allocates RFC numbers and other 
identifiers (the current IETF stable identifiers) when the document 


is near the end of the publication process. Having identifiers 
allocated early was considered, but a definite need could not be 
established. 


Derived Requirements: 


o Req-PERMID-1 - The IETF technical publisher should allocate stable 
identifiers as part of the publication process. 


Mankin & Hayes Informational [Page 11] 


RFC 4714 IETF Technical Publisher Requirements October 2006 


3:2 


3; 


o Req-PERMID-2 - The IETF technical publisher should assign 
additional permanent identifiers associated with various classes 
of documents as directed by the appropriate authority. For the 
IETF standards process stream, that authority is the IESG. 


Document Format Conversions 


Task Description: The technical publisher is responsible for 
converting the documents into one or more output formats (e.g., text, 
Portable Document Format (PDF)). In some standards organizations, 
the technical publisher may be required to accept input documents in 
various formats and produce a homogeneous set of output documents. 


Discussion: Currently, the RFC Editor accepts input as an ASCII text 
file. The RFC Editor has also accepted supplementary formats that 
were used to generate the ASCII text (XML and NROFF). The documents 
are published as ASCII text and PDF files. 


Derived Requirements: 


o Req-DOCCONVERT-1 - The IETF technical publisher should accept as 
input ASCII text files and publish documents as ASCII text files 
and PDF files. 


o Req-DOCCONVERT-2 - The technical publisher should accept 
supplemental files that may contain information such as code, 
formal descriptions (e.g., XML, ASN.1) graphics, data files, etc. 
Supplemental files may also include enhanced versions of the 
document containing graphics or sections not presentable in text 
format. Any supplemental files, barring any changes to the IETF 
process rules, will be associated with the published IETF 
documents, but may not be editable by the publisher. 


10. Language Translation 


Task Description: Some standards organizations require publication of 
documents in multiple languages. This translation is the 
responsibility of the technical publisher. 


Discussion: IETF specifications are published only in English. 


Derived Requirements: none 


11. Publication Status Tracking 


Task Description: The technical publisher should have the ability to 
provide status information on the status of a document. This may 
involve developing a process model or a checklist and providing 


Mankin & Hayes Informational [Page 12] 


RFC 4714 IETF Technical Publisher Requirements October 2006 


information on a document’s state, outstanding issues, and 
responsibility tokens. Depending on the need for transparency, this 
information may need to be available online and continuously updated. 


Discussion: The RFC Editor currently provides status information via 
the RFC Editor queue. Each document is attributed a status (e.g., 
AUTH48, RFC-EDITOR, IANA, ISR). Items may stay in the queue for a 
long time without changing status. This status tracking information 
is not integrated with the IESG tracking tools. Within the IETF, the 
Process and Tools (PROTO) team is considering requirements for 
marking the token-holder accurately during long waiting periods, and 
others are looking into improved notification tools. Requirements on 
the IETF technical publisher for improved status integration and 
visibility could be met by collaborations with these efforts, by 
providing public access to email logs regarding publications, or by 
some other proposal. 


Derived Requirements: 


o Req-STATUSTRK-1 - The IETF technical publisher should make state 
information publicly available for each document in the 


publication process. It is desirable that this information be 
available through a documented interface to facilitate tools 
development. 


o Req-STATUSTRK-2 - The IETF technical publisher should integrate 
its state information with the IETF tools to provide end-to-end 
status tracking of documents. For the documents in the IETF 
standards process stream, it is expected that documents should be 
able to move seamlessly from the IETF standards tracking system 
into the technical publication tracking system. 


o Req-STATUSTRK-3 - The IETF technical publisher should provide 
external visibility of not only the fact that a document is in an 
extended waiting period but also the token-holder and 
circumstances of the wait. 


3.12. Expedited Handling 


Task Description: In some cases (such as when the documents are 
needed by another standards body), it should be possible for the 
approving organization to request expedited publication of a 
document. Ideally, this should not skip any of the publication 
steps, but allocates it higher priority in the work queue to ensure 
earlier publication than normal. Expedited publication should be 
used sparingly since as with any priority scheme, overuse will negate 
its benefits. 
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Discussion: The fast-tracking procedure is used to expedite 
publication of a document at the request of the IESG. Fast-tracking 
is generally employed when an external organization has a looming 
publication deadline and a need to reference a document currently in 
the RFC Editor’s queue. Having short publication times would likely 
reduce the need for fast-tracking. 


Since fast-tracking is disruptive to the work flow, it is recommended 
that expedited handling be phased out as soon as alternative ways of 


achieving timely publication are in place. 


Derived Requirements: 


o Req-EXPEDITE-1 - The IETF technical publisher should expedite the 
processing of specific documents at the request of an appropriate 
authority. For the IETF standards process stream, that authority 
is the IESG or the IAB. 


3.13. Exception Handling 


Task Description: It should be possible for various reasons for a 
document to be withdrawn from publication or the publication to be 
put on hold. Reasons for this could be due to an appeals process, 
detection of a serious technical flaw, or determination that the 
document is unsuitable for publication. 


Discussion: For various reasons, a document can be withdrawn before 
publication. 


Derived Requirements: 


o Req-EXCEPTIONS-1 - The IETF technical publisher should permit 
documents to be withdrawn from publication at the direction of an 
appropriate authority. For the IETF standards process stream, 
that authority is the IESG. 


o Req-EXCEPTIONS-2 - The IETF technical publisher should permit 
documents to be put on hold awaiting the outcome of an appeal at 
the direction of an appropriate authority. For the IETF standards 
process stream, that authority is the IESG. 


3.14. Notification of Publication 
Task Description: The technical publisher should provide a mechanism 


for alerting the community at large of the availability of published 
documents. 
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Discussion: The RFC Editor notifies the community of document 
publication on the rfc-dist and ietf-announce mailing lists. 


Derived Requirements: 


o Req-PUBNOTIFY-1 - The IETF technical publisher should announce the 
availability of published documents. 


3.15. Post-publication Corrections (errata) 


Task Description: If corrections are identified after publication, 
the technical publisher should be able to publish errata that can be 
linked with the original document. 


Discussion: The RFC Editor maintains a list of errata. Pointers to 
relevant errata are presented as output from the RFC Editor search 
engine. 


Derived Requirements: 


o Req-ERRATA-1 - The IETF technical publisher should maintain errata 
for published documents. The process for review, updating, and 
approval of errata for IETF documents will be defined by the IETF. 


o Req-ERRATA-2 - The IETF technical publisher should provide 
information on relevant errata as part of the information 
associated with an RFC. 


3.16. Indexing: Maintenance of the Catalog 


Task Description: The technical publisher normally provides and 
maintains the master catalog of publications of that organization. 

As the publishers of the organization’s output, the technical 
publisher is expected to be the definitive source of publications and 
the maintainer of the database of published documents. This also 
includes the cataloging and storage of meta-information associated 
with documents such as their history, status (e.g., updated, 
obsoleted), document categories (e.g., standard, draft standard, 
BCP). 


Discussion: The RFC Editor maintains the catalog. The RFC Editor is 
also responsible for the permanent archival of specifications. 
Meta-information associated with an RFC should also be maintained. 
Since this is the definitive archive, sufficient security should be 
in place to prevent tampering with approved documents. 
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Derived Requirements: 


o Req-INDEX-1 - The IETF technical publisher should maintain the 
index of all IETF published documents. It is desirable that the 
interface to the index be documented to facilitate tools 
development. 


o Req-INDEX-2 - The IETF technical publisher should provide the 
permanent archive for published documents. 


o Req-INDEX-3 - Meta-information associated with a published 
document must be stored and updated as its status changes. 


o Req-INDEX-4 - The archive must be sufficiently secure to prevent 
the modification of published documents by external parties. 


o Req-INDEX-5 - The IETF technical publisher should provide the 
permanent archive of any source documents associated with a 
published specification. 


o Req-INDEX-6 - An appropriate authority can indicate to the 
publisher that it should change the status of a document (e.g., to 
Historical) and this should be reflected in the index. For the 
IETF standards process stream, the indicating authority is the 
IESG. 


3.17. Access to Published Documents 


Task Description: The technical publisher should facilitate access to 


the documents published. It is assumed that the technical publisher 
will provide online tools to search for and find information within 
the archive of published documents. These access tools should 


facilitate understanding the state of the document (e.g., 
identification of replacement or updated documents, linkage to 
pertinent errata). 


Discussion: Documents and status may be accessed via the RFC Editor’s 
web page. 


Derived Requirements: 


o Req-PUBACCESS-1 - The IETF technical publisher should provide 
search tools for finding and retrieving published documents. 


o Req-PUBACCESS-2 - The IETF technical publisher tool should return 


relevant meta-information associated with a published document 
(e.g., category of document, type of standard (if standards 


Mankin & Hayes Informational [Page 16] 


RFC 4714 IETF Technical Publisher Requirements October 2006 


track), obsoleted by or updated by information, associated 
errata). 


o Req-PUBACCESS-3 - The IETF technical publication search tools 
should be integrated with the IETF search tools. For the IETF 
standards process stream, this refers to integration with the 
search tools used by the IETF standards process. 


3.18. Maintenance of a Vocabulary Document 


Task Description: Some standards organizations require the technical 
publisher to maintain a publicly available vocabulary document or 
database containing common terms and acronyms. The goal is to 
provide consistency of terminology between documents. 


Discussion: The RFC Editor does not maintain a public document or 
database of terms or acronyms. 


Derived Requirements: none 
3.19. Providing Publication Statistics and Status Reports 


Task Description: The technical publisher may be required to 
periodically or continuously measure its performance. In many 
standards organizations, performance targets are set in terms of 
timeliness, throughput, etc. 


Discussion: The IETF technical publisher currently provides monthly 
statistics on arrivals and completions of documents by category. In 
addition, a status report is provided at each IETF meeting. Other 
statistics can be used to judge the health of the editing process. 
Many of these statistics could be gathered using sampling techniques 
to avoid excessive load on the technical publisher. 


Derived Requirements: 


o Req-STATS-1 - The IETF technical publisher should provide publicly 
available monthly statistics on average queue times and documents 
processed. The presentation should provide a historical context 
to identify trends (see Goal-THROUGHPUT-1). For the IETF 
standards process, this should include queue arrivals, 
completions, documents in the queue, and the number of documents 
in each state at the end of the month. 


o Req-STATS-2 - The IETF technical publisher should provide periodic 


status reports at the IETF meetings to apprise the community of 
its work and performance. 
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o Req-STATS-3 - The IETF technical publisher should provide publicly 
available monthly statistics on the types of editorial corrections 
being found during reviews as well as the percentage of 
corrections that are rejected by the authors. 


o Req-STATS-4 - The IETF technical publisher should provide publicly 
available monthly statistics on author-requested changes to 
documents under publication. This statistic should also include 
changes required by other authorities outside of the technical 


publisher empowered to make changes. For the IETF standards 
process, the designated authority would be the IESG or its 
designees. 

3.20. Process and Document Evolution 


Task Description: The guidelines and rules for an organization’s 
publication output will change over time. New sections will be added 
to documents, styles and conventions will change, boilerplate will be 


changed, etc. Similarly, the specific processes for publication of a 
specification will change. The technical publisher is expected to be 
involved in these discussions and accommodate these changes as 
required. 


Discussion: Over time, the IETF consensus on what should be ina 
published document has changed. Processes interfacing with the 
publisher have also changed. Such changes are likely to continue in 
the future. The RFC Editor has been involved in such discussions and 
provided guides, policies, faqs, etc. to document the current 
expectations on published documents. 


Derived Requirements: 


o Req-PROCESSCHG-1 - The IETF technical publisher should participate 
in the discussions of changes to author guidelines and publication 
process changes. 


o Req-PROCESSCHG-2 - The IETF technical publisher should participate 
in and support process experiments involving the technical 
publication process. 


3.21. Tutorial and Help Services 


Task Description: The technical publisher may be required to provide 
tutorials, mentoring, help desks, online tools, etc. to facilitate 
smooth interaction with the technical publisher and to increase the 
IETF community’s awareness of document guidelines, procedures, etc. 
In many organizations, the publisher maintains a style manual giving 
explicit guidance to authors on how to write a specification. 
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Discussion: Guidelines are provided to the authors on how to write an 
RFC as well as occasional tutorial presentations. The RFC Editor 
provides a help desk at IETF meetings. 


Derived Requirements: 


o Req-PUBHELP-1 - The IETF technical publisher should provide and 
maintain documentation giving guidance to authors on the layout, 
structure, expectations, etc. required to develop documents 
suitable for publication. For the IETF standards process stream, 
the technical publisher should follow IESG guidance in specifying 
documentation guidelines. 


o Req-PUBHELP-2 - The IETF technical publisher should provide 
tutorials to the IETF community to educate authors on the 
processes and expectations of the IETF technical publisher. 


o Req-PUBHELP-3 - The IETF technical publisher should provide a 
contact email address and correspond as required to progress the 
publication work. The publisher should address queries from both 
inside and outside of the IETF community. 


o Req-PUBHELP-4 - The IETF technical publisher should provide a help 
desk at IETF meetings. 


3.22. Liaison and Communication Support 


Task Description: It is very valuable for the technical publisher of 
an organization to have good information and communication about the 
work streams that will result in publication streams. In order to 
ensure a wide communication channel for the work, the technical 
publisher holds a liaison position on the IESG, where there can be 
valuable give-and-take about matters concerning the IETF standards 
stream. 


Discussion: The RFC Editor currently maintains a liaison position 
with the IESG. Although not specifically addressed in these 
requirements, the RFC Editor also maintains a liaison position toward 
the IAB. 


Derived Requirements: 


o Req-LIAISON-1 - Through a liaison participant, the technical 
publisher should take part in meetings and activities as required 
in order to be aware of ongoing activities related to the work 
streams. For the IETF standards stream the technical publisher 
should participate in IESG formal meetings, IESG face-to-face 
activities at IETF, and other activities such as retreats. 
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4. Technical Publisher Performance Goals 


Technical publishers are typically measured not only on what they do 
but how well they perform the tasks. The expectations in this 
section are treated as goals instead of requirements because: 


- Achieving a given level of performance is not totally under the 
control of the technical publisher. Publication is a process and 
the goals are of the process, not just the publisher. 


- The actual performance objectives will be set contractually. The 
values herein represent values that the IETF community feels are 
desirable and reasonable for work progress without consideration 
of financial or other factors. 


Goals are set forth in the following areas: 
1. Publication timeframes 
2. Publication throughput 

4.1. Publication Timeframes 


Goal Description: This is a measure of the time from entry into the 
RFC Editor queue until the documents are published. The metrics are 
defined in (req-STATS-1). 


Discussion: Long publication times create both internal and external 
difficulties. Internal difficulties include the migration of authors 
to other activities and the accumulation of tempting post-approval 
fixes to be added to the document. External difficulties include the 
inability of other standards organizations to reference IETF 
publications for lack of an RFC number. 


Derived Goals: 


Oo Goal-TIMEFRAMES-1 - The consensus of the IETF community is that an 
average publication time of under a month is desirable. It is 
understood that in some cases there will be delays outside of the 
publisher’s control. The actual performance targets and metrics 
are expected to be determined as part of the contract negotiation 
process. 


Oo Goal-TIMEFRAMES-2 - The consensus of the IETF community is that 
the time required for a pre-approval review should be under 10 
days. The actual performance targets and metrics are expected to 
be determined as part of the contract negotiation process. 
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4.2. Publication Throughput 


Goal Description: The number of documents published during a given 


time period is a measure of publisher throughput. Some publishers 
also provide the data in terms of pages produced. The counts should 
be separated by categories of documents. The metrics are defined in 


(req-STATS-1). 


Discussion: The RFC Editor currently provides monthly statistics on 
the arrival and completion of documents into the RFC queue. This is 
sorted by category of document. This provides a measure of the 
delays in the publication process. 


Derived Goals: 


Oo Goal-THROUGHPUT-1 - Although minor variations are expected, there 
should be no long-term growth trend in the length of the 
publication queue. The actual performance targets and metrics are 
expected to be determined as part of the contract negotiation 
process. 


5. IETF Implications of Technical Publication Requirements 


Requirements on the technical publication process have so far been 
stated in terms of requirements on the technical publisher. However, 
it must be recognized that many of these requirements have 


implications for the processes and tools within the IETF itself. It 
is anticipated that these processes will be documented in companion 
documents. 


The following is a list of potential issues that should be addressed 
within the IETF based on the requirements applied to the technical 
publisher: 


o Pre- vs. Post-approval Editing: If emphasis switches from post- 
approval editing to pre-approval editing, then IETF processes must 
be adapted to make use of this service. The processes for post- 
approval editing can also be streamlined. 


o Post-approval Editorial Cleanup: The IETF must define under what 
conditions the publisher should be instructed to bypass or 
minimize post-approval editing. 


O Approval of Post-approval, Pre-publication Technical Corrections: 
Since the technical publisher can only accept approved changes, it 
must be clear who is allowed to approve technical changes. This 
process within the IETF needs to be decided and documented. 
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o Allocation of Permanent Stable Identifiers: The IETF needs to 
clearly identify the naming/numbering schemes and classes of 
documents to which those names and numbers apply. Furthermore, 
the responsibility for allocation of those names/numbers needs to 
be identified. 


o Expedited Handling: If publication timelines can be reduced 
sufficiently, then expedited handling may no longer be needed. 


o Post-publication Corrections: Appropriate processes must be 
defined with the IETF to ensure that errata are appropriately 
vetted and authorized. 


o Indexing: Appropriate processes must be defined within the IETF to 
decide and inform the technical publisher of status changes to 
published documents as the result of an appeal, legal action, or 
some other procedural action. 


6. IANA Considerations 


Any new requirements that result from this discussion need to be 
reviewed by IANA and the IETF to understand to what extent, if any, 
the work flow of the documents through IANA is affected. 


Interactions with IANA on population of parameter values is discussed 
in Section 3.6. 


7. Security Considerations 


There is a tussle between the sought-for improvements in readability 
and the specific language that has often been negotiated carefully 
for the security content of IETF documents. As with other text, 
extreme caution is needed in modifying any text in the security 
considerations. This issue is assumed to have been dealt with under 
Section 3.3. 


The processes for the publication of documents should prevent the 
introduction of unapproved changes (see Section 3.7). Since the IETF 
publisher maintains the index of publications, sufficient security 
should be in place to prevent these published documents from being 
changed by external parties (see Section 3.16) 
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